-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it easy to test-publish packages #2053
base: trunk
Are you sure you want to change the base?
Conversation
95d105a
to
e3a790e
Compare
To prevent accidentally committing .npmrc with the registry set to local.
e3a790e
to
26d20c1
Compare
be485bd
to
fad3d74
Compare
fad3d74
to
09076ae
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made a number of assumptions when documenting the release process, so the docs might not be correct. I appreciate any input you might have.
Playground's versioning strategy is to use the same version for all packages, **but** only packages that need to be released are bumped to the new version. As an example, lets consider the following scenario: | ||
|
||
- All packages are currently at `v1.0.0` | ||
- The following packages have changes since `v1.0.0`: `@wp-playground/cli` and `@wp-playground/remote` | ||
|
||
When we issue a new release, only `@wp-playground/cli` and `@wp-playground/remote` will be bumped to `v1.0.1`, and all other packages will remain at `v1.0.0`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% this is correct, I appreciate any feedback you might have about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is almost correct, I'd add a bit about dependencies, e.g. if we also updated @wp-playground/blueprints
then @wp-playground/client
would also be version bumped to consume the latest Blueprints version.
|
||
### Authenticating with npmjs.com | ||
|
||
TODO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I've heard someone (maybe @bgrgicak ?) mention that they were able to publish to npmjs.com from their local machine, but I'm not 100% sure of this. If you have done it before, could you comment here on how that process exactly works? Thanks in advance. I will then incorporate it into the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a npm run release
command that you can run locally. AFAIR it will ask you for npmjs.org credentials.
HAS_LOCAL_REGISTRY=$(git diff --cached --name-only .npmrc | xargs grep -n "registry=http://localhost:4873/") | ||
if [ -n "${HAS_LOCAL_REGISTRY}" ]; then | ||
echo "The commit was rejected due to attempting to commit .npmrc with the registry set to the local registry." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good check! I'm wondering – is it possible to use a file that's .gitignore
-d instead of a versioned one like .npmrc
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, could this focus more on the next step? As in tell the user to run npm run local-registry:disable
npm run release | ||
``` | ||
|
||
### Publishing to a local registry |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
H2 perhaps? No strong opinions
### Publishing to a local registry | |
## Publishing to a local registry |
@@ -13,10 +13,15 @@ | |||
"format": "nx format", | |||
"format:uncommitted": "nx format --fix --parallel --uncommitted", | |||
"lint": "nx run-many --all --target=lint", | |||
"local-registry:clear": "rm -rf tmp/verdaccio", | |||
"local-registry:enable": "./tools/scripts/local-registry.mjs enable", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would there be any downside to running npm config set
directly?
Thank you @psrpinto! It looks great overall, I just left a few minor notes |
Thanks for reviewing @adamziel!, Your notes are on point, I will work on addressing them. |
Previously, in #1924, I needed to test-publish a package without actually publishing it to NPM. At the time, I used an ad-hoc (and cumbersome) way to do so that got the job done (see PR description on #1924), but @adamziel suggested it could be useful to document such a process.
As such, this PR does three things:
npm
from npmjs.com to the local one, and vice-versaThe rendered documentation is here.
Testing instructions
Please follow the instructions in the docs to publish packages to a local registry.
Summary of changes
start
the local registryclear
the local registry (removes all data used by the local registry)enable
the local registry (makesnpm
commands target the local registry)disable
the local registry (makesnpm
commands target npmjs.com)npmrc
when the local registry is enabledScreen captures
Local package registry
Docs
References